This patent application is related to U.S. Ser. No. 08/019,600 filed concurrently herewith, for a xe2x80x9cA Method and Apparatus for Overriding Resource Maps in a Computer Systemxe2x80x9d by Dean Yu and Chris Derossi, which is hereby incorporated by reference.
The following documents are herein incorporated by reference: Inside the Macintosh, Volume IV, Addision-Wesley Publishing Company, Inc. (1987); and Apple Macintosh Family Hardware Reference, Addison-Wesley Publishing Company, Inc. (1988).
1. Field of the Invention
This invention relates generally to computer operating system boot sequences and initialization methods and apparatus.
2. Summary of the Related Technology
System Software as it""s developed today is tied very closely with the particular Macintosh machines that it supports. In some cases, this makes a lot of sense since the system software has to interface with the hardware. In other cases, though, this is an artificial limitation. For example, System 6.0.5 doesn""t support the Macintosh Classic because the Classic was released after System 6.0.5. However, since the Classic is so similar to previous machines, namely the Macintosh SE, System 6.0.5 would work just fine if it weren""t for the check made by the boot code that prevents it from loading.
Frequently there will be changes to the hardware which require changes to the system software. In many cases, the changes needed in the system software are minor compared to the task of developing and releasing an entirely new version. But, in the past, there was no way to provide incremental changes without releasing a whole new version of system software. Thus, each new set of machines required a complete and separate software development effort.
Hardware support releases of system software are released later, and have higher version numbers than the version on which the release was based. Customers perceive that the hardware support version is superior because it has a higher version number. Customers then want the newer version, even if they do not have one of the new machines that require the new software. Exacerbating the matter is the fact that hardware support releases often supply additional functionality, causing developers and customers to want the new release for all machines. Hardware support features are required by new machines, thus new software releases are required to implement small human interface elements. For example, System 6.0.5 could not ship with Classic because xe2x80x9cAbout the Finder . . .xe2x80x9d would have called it a Macintosh SE and given it the wrong icon.
In the past, operating systems were developed with a particular processor and hardware environment in mind. System designers tailored the operating system to run on a particular processor and hardware configuration. While it has been considered good programming design methodology to take advantage of the underlying hardware architecture, the operating system was limited to the particular processor and hardware environment for which it was written. The operating systems were not portable. This was so because the operating system software had to interface with and control the computer system hardware. Although such operating systems may have operated satisfactorily on one particular type of processor, they would not run on another type of processor. As a result, prior operating systems were inflexible.
In the past, an entirely new version of the operating system software usually had to be developed for each new type machine. An individual development effort was required to code and release a new version of the operating system whenever a new processor or hardware configuration change was implemented. Such development efforts were usually very expensive and time consuming.
In order for the operating system to accommodate different hardware environments, system designers were usually forced to release a new version of the operating system when new hardware platforms became available. Many times, it did not take long for the latest version of an operating system to be upstaged by a newer version generated to accommodate a new hardware configuration. As an undesirable result of this, different versions of the same operating systems would proliferate.
Even in the absence of new hardware platforms using new machine designs, there were other changes in hardware that required changes to the system software. In many cases, the changes to the hardware were relatively minor compared to the task of developing and releasing an entirely new version of the operating system software. Nevertheless, these ad hoc efforts at system design negatively impacted engineering resources, quality control, marketing, and profitability. The proliferation of different versions of an operating system created significant difficulties for those attending to version control and documentation. The problems normally encountered in debugging software and beta testing were greatly exacerbated by the proliferation of different versions of operating system software.
In the past, attempts have been made to extend the functionality of an operating system software release by patching or implementing new functions. These functionally extensible patch files were sometimes referred to as xe2x80x9cextensions.xe2x80x9d For example, to add new functionality that allows an application program to play movies within a document, an attempt might be made to extend the system software functionality with an extension file. Extensions were sometimes referred to as xe2x80x9cINITxe2x80x9d files, because of their file type in the Macintosh computer environment provided by Apple Computer, Inc. Extension files were patch files that relied on the system boot routine to bring up the system from a power on reset state to a fully operational state.
Patch files contained changes to system software that were called in and executed to augment system software after system initialization by the boot routine. These patch files would change code in the operating system to accommodate new machines and new hardware configurations, and to update system software in order to fix problems or add functionality after the release of a particular version of an operating system.
In addition to the above described problems, application programs that were written to run on a particular hardware platform might not run on later versions of the hardware, because the application program might not be compatible with the new version of the operating system required for a new hardware configuration different from that on which the application program was originally designed to run.
Further problems were created because the way that system programmers dealt with the inherent incompatibility between most underlying hardware architecture sometimes had the undesirable result of imposing artificial limitations on the software. Typically, a status check of the hardware configuration would be performed by the operating system during the system start-up, or boot procedure. Oftentimes, an operating system designed to run on a first hardware platform would be prevented from loading onto a second slightly different platform, when the status check determined that the hardware platform was not the one that the operating system expected. The system would halt, even though the operating system might be capable of actually running on that slightly different hardware platform. Thus, the artificial barrier created by the common practice of performing such status checks would make operating systems that were designed to run on a particular hardware platform incompatible with any different hardware platform, regardless of the similarities between the two hardware platforms. Nevertheless, such status checks were often considered to be a necessity in order to prevent computer system crashes, because of the lack of portability between most hardware platforms.
Customers were often confused when numerous ad hoc versions of system software appeared on the market with higher version numbers than the one the customer had just purchased. Customers typically perceive software having a higher version number to be superior over software with a lower version number, even though the difference in version was only to accommodate hardware which the customer did not utilize. This practice also tended to raise customer concerns as to why frequent software revisions were being released.
The system software vendor must test its latest released version of operating system software with all existing computer hardware, past and present. Of course, as the number of different hardware systems increases, so does the requirement for software testing of new system software versions.
It is apparent from the above discussion of problems in conventional systems, that there is a need for an improved method and apparatus to accommodate new computer hardware developments with an existing software operating system.
This invention relates generally to the concept of using modularized software with new computer systems and more particularly to a technique that employs a separate modular software file having all patches, code, data and resources needed to initialize a particular computer system.
The present inventors have developed new operating system architectures that are designed to solve these problems. Portions of the boot or start-up routine have been moved out of read only memory (ROM) and into files so that the boot routine is no longer hard coded and inflexible. As much of the boot procedure as possible is located in a file on disk instead of ROM so that the boot procedure can be changed by providing a new boot procedure file on disk.
The present invention provides a method and apparatus for updating existing computer operating system software so that the existing version of the system software will operate with and utilize new functionalities and developments in computer operating system software and the underlying computer hardware architecture. The method and apparatus of the present invention utilizes software modules, referred to as a xe2x80x9cSystem Enablerxe2x80x9d or xe2x80x9cGibblyxe2x80x9d, which is specific to a particular computer system""s implementation in hardware and software. Whenever a new computer system is introduced, the correct new version of a software module is also included with the computer system. The operating system software of the present invention utilizes a separate file which contains all of the patches, code, data and resources needed to utilize specific new hardware. This file is called the xe2x80x9cSystem Enablerxe2x80x9d or xe2x80x9cGibblyxe2x80x9d.
By removing the hardware specific knowledge from the operating system software, a new version of the operating system software is not required every time new hardware is utilized in a computer system. Instead, the present invention allows the most recent generic version of a software operating system to be utilized with subsequently introduced computer hardware systems by supplying the appropriate System Enabler with the new computer system.
The present invention reduces the number of new versions of operating system software required to support new computer system hardware. The present invention permits hardware specific changes to be made to the operating system software early in the boot process.
A feature of the present invention is the ability to boot new hardware implementations developed subsequently to the current operating system software. Another feature of the present invention is use of the most recent time stamped Gibbly, or some other selection criteria such as machine state, operating mode, or other criteria to select the most appropriate Gibbly for starting up the computer system.
Other and further features and advantages will be apparent from the following description of a presently preferred embodiment of the invention, given for the purpose of disclosure and taken in conjunction with the accompanying drawings.